Skip to content

OSAL Firmware update implementation for EFR32 Wi-SUN #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 46 commits into
base: osal
Choose a base branch
from

Conversation

ismilak
Copy link
Collaborator

@ismilak ismilak commented Feb 26, 2025

The PR is based on osal_fw_rw_api branch and it consist 3 well separated topics:

1. Fixed build issues for all platforms: linux, FeeRTOS, efr32_wisun

2. Refactor OSAL APIs and introduce new APIs.

  • Slot header and related definitions are moved to OSAL

  • osal_read_firmware() and osal_write_firmware() are refactored: The original APIs were designed to write and read the entire firmware image to the storage, on linux, into a file. For EFR32 platform we need to use gecko bootloader storage to store the images and the image cannot be stored in the RAM. The new osal_read_firmware_slothdr() and osal_write_firmware_slothdr() can be used to store the header only. For EFR32 NVM3 (non volatile memory section) is used to store the headers

  • osal_write_storage() API is introduced as a portable interface to implement write storage operation for storing data chunks in the image block POST request. For linux it's a simple memcpy, for EFR32, Gecko bootloader write storage is used.

  • osal_erase_storage() API is implemented to erase the particular storage slot. Gecko Bootloader requires erase operation before the write operations to store a new image to the "upload" slot.

  • osal_deploy_and_reboot_firmware() API is implemented for having portable bootloader API calls. Gecko Bootloader requires "verify image", "set image to boatload" and "reboot and install" calls for EFR32. The bootable image slot should contain the GBL (Gecko Bootloader) file content.

  • osal_copy_firmware_slot() API is introduced for having copy operation. For "backup" request, we need to copy "upload" storage slot to the "backup" storage slot, that is not a simple memcpy operation.

3. Implement APIs and TLVs for EFR32, refactor existing platform TLVs.

  • Initialise 2 Gecko bootloader storage slot with 512KB size: Upload, Backup storage slots. Run image storage slot is the internal application flash in EFR32 SoCs, therefore it is not implemented as available storage slot.

  • All the APIs are implemented for all platforms. If the platform doesn't support the particular API, an empty implementation is provided.

  • Implemented EFR32 TLVs: in image block post request, we need to remove the Csmp header from the first chunk, because it can't be stored in the bootloader slot. In the TLV, the bootloader slot offset is calculated and managed separately from firmware image offset.

  • Implemented OSAL APIs for EFR32: Gecko Bootloader and NVM3 API are integrated. NVM3 is used for storing storage header for all slots: Run, Upload, Backup.

  • Csmp header structure is refactored: "image" allocation is removed from the structure definition (only for EFR32)

Improvement ideas

  • emulate storage slot implementation for linux: creating a file per storage with 1MB size, that is filled with dummy data. Using fseek API, the chunks cane be stored directly in to the file, image allocations is not required. An other benefit is matching with other platforms

  • remove tlvs port sources. If the OSAL API-s are well-defined, and can be used in the TLV handlers, portable TLV handlers are not required anymore (The same recommendation in osal_fw_rw_api PR)

  • remove code duplications, move platform specific and common source to OSAL: csmp_info.h and csmpinfo.h are the same. In this PR the Csmp header definitions is moved into OSAL too. Library sources can use the OSAL API.

@ismilak
Copy link
Collaborator Author

ismilak commented Feb 27, 2025

Tested Linux and EFR32 version:

  • With a fresh new deploy, downloading 'opencsmp-node-6.8-sample-image.bin':
  • Set upload slot as backup image
  • Perform scheduled reboot and install from FND (EFR32 is failed due to invalid images)
  • Verify the downloaded images with getting slots from external flash (EFR32). I attached the slot hex files to compare.
    All the tests are succeeded.
    upload-slot
    backup-slot

@ismilak
Copy link
Collaborator Author

ismilak commented Mar 24, 2025

FYI Critical memory leak is solved in 3bba235

It's a general issue for all platforms, since it's in csmp_firmwareMgmt.c that is a not platform specific library source.

@ismilak
Copy link
Collaborator Author

ismilak commented Mar 25, 2025

EFR32 test result with real gbl file (lzma compression, ~389KB)

  • Upload CsmpAgent_efr32_wisun_6.3.0.gbl.bin to Cisco FND succesfully
  • Start and follow the firmware update on EFR32 Wi-SUN device.
  • Schedule a reboot in FND
  • Check the new firmware runtime as well: register to the FND

All the tests are passed. The sample log shows the output after rebooting the new firmware (it prints "!!!! NEW Csmp Agent Lib Sample Application). The device with the new firmware operates without any problem: it was registered successfully to Cisco FND.
Screenshot 2025-03-25 at 11 51 19

ismilak added 26 commits June 2, 2025 19:29
@ismilak ismilak force-pushed the osal_fw_rw_api_efr32_wisun branch from 1fbefd0 to bd77d6f Compare June 9, 2025 18:23
@ismilak
Copy link
Collaborator Author

ismilak commented Jun 9, 2025

Updated PR to be aligned with osal HEAD:

  • OSAL read/write is void implementation for EFR32, since the platform doesn't support filesystem. Anyway the linux usage can be replaced by write header in Sample app init.
  • OSAL write slot API has been removed, the gecko bootloader call is added to the appropriate TLV handler
  • OSAL erase slot API has been removed, the gecko bootloader call is added to the appropriate TLV handler
  • OSAL copy firmware API signature has been changed.
  • OSAL deploy and reboot firmware has been removed, the gecko bootloader calls are added to the appropriate TLV handler
  • From several definitions, OSAL prefix has been removed

Test results:

  • EFR32 tests: reboot request, firmware upload and scheduled boot to new firmware, backup request have been tested successfully.
    Note: Backup POST request handler was called multiple times, since more request were sent by Cisco FND. Probably the long flash erase time causes on EFR32.

@ismilak
Copy link
Collaborator Author

ismilak commented Jun 11, 2025

@manojnacsl As we discussed, I describe the improvement ideas.
The osal_write_firmware API can be replaced by write slot header: https://github.com/CiscoDevNet/csmp-agent-lib/pull/30/files#diff-3faa770d6549b322b0ab405c93fa291824e72a2d87bc17b16137b77e0b52175bR73

In this case we don't need osal_write_firmware, that writes data to the file from offset 0.
Note: osal_write_storage_slot has been removed that provides solution to set the offset in the file or flash. The related gecko bootloader call has been added to the TLV handler: https://github.com/CiscoDevNet/csmp-agent-lib/pull/30/files#diff-48b4aae6d47df83d70dcd847bfa806320f039db6ce28b9e77132036d3489008dR823

I note that, more gecko bootloader API calls are moved to the appropriate TLV handler, they have been removed from OSAL. If we can operates only with OSAL APIs in the TLV handlers, we can have only one TLV implementation, and the abstraction can be solved in OSAL only, in this case we can remove the TLV abstraction later.

To compare extended OSAL APIs with the current head, you can use this commit as reference (diff osal.h)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants